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ABSTRACT 

Seattle University has an industrially sponsored, yearlong, senior design program that has been 
in existence for more than 20 years. Students work in teams of three or four under the guidance 
of a liaison from the sponsoring agency and a faculty advisor. The students prepare a proposal in 
the fall quarter detailing their plan and a design report in spring quarter. Technical writing is an 
important component in the design program. For the past two decades the Department of Civil 
and Environmental Engineering has partnered with the English Department faculty members and 
students, technical writers from industry, and engineering practitioners to improve the technical 
writing component. This paper discusses the evolution and implementation of the technical writ¬ 
ing component within senior design, describes the experience and the lessons learned over the 
years. It also presents the assessment results and/or reflections by the various constituents. The 
experience shared should be helpful to other senior design programs. 

Keywords: senior design program, technical communication, university-industry partnership 


INTRODUCTION 


Technical writing is vital for engineers. It is estimated a typical engineer spends one third to half 
a work-day writing proposals, reports, memos and other documents [1, 2], Therefore, there is an 
increasing demand from industry employers that students possess strong technical writing skills 
at the time of graduation. Engineering documents have to be well organized, reader friendly, ac¬ 
curate in the information they provide, clearly written, concise, grammatically correct and have to 
look professional. 

To meet the industry’s demand, ABET 2009-10 Criterion 3 requires that all engineering gradu¬ 
ates demonstrate an ability to communicate effectively at the time of graduation (criterion g of 
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a-k program outcomes) [3]. Also, ABET 2009-10 Criterion 5 requires that students participate in a 
major design experience prior to graduation. These criteria have been in place since 2000. However, 
capstone projects have been an integral part of engineering curricula long before that. In response 
to the ABET 2000 criteria several universities took the initiative to start new senior capstone pro¬ 
grams or strengthen existing ones. In most universities, the capstone program spans one or two 
semesters and requires documentation of the project work through written proposals, progress re¬ 
ports and final reports. Laboratory reports and term papers in various courses typically go through 
a single step of submittal and review due to student/faculty workload and time constraints during 
a semester. However, documents prepared for the senior capstone project, especially in programs 
that last longer than one semester, provide the much needed time to go through multiple revisions 
of document thereby strengthening the technical writing skills of students. 

The capstone program at Seattle University’s College of Science and Engineering has been 
in existence for more than 20 years. Over the years, various constituents have participated in 
improving the technical writing component of the program. Seattle University (SU) English 
department faculty members, SU Writing Center (student) consultants, professional technical 
writers who have experience in science and/or engineering consulting, and practicing engineer¬ 
ing professionals have worked with engineering faculty members and students in this process. 
The aim of this paper is to discuss the evolution of technical writing within the Civil Engineering 
Department over the past two decades, to describe the experience and the lessons learned over 
time and to summarize the assessment and reflections by alumni, students, practicing engineers 
and faculty members. 


BACKGROUND 


Students usually lack confidence in writing. Most students decide to go into engineering because 
of their strong math and science skills and not because of their passion for writing. This dislike for, 
and fear of, writing is exacerbated in engineering students because the students are not familiar with 
the conventions and genre of technical writing, and in most cases are still learning about the sub¬ 
ject/project that they are writing about [4], To alleviate the inhibitions of the engineering students, 
and to make them better technical writers, academia has come up with numerous creative ideas and 
has made several resources available to them throughout the undergraduate experience. 

At several universities, interdisciplinary technical communication courses have been established 
jointly by the English (or communication, humanities or journalism) department and colleagues in 
technical disciplines. Deborah Andrews, an English department faculty member at the University 
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of Delaware, summarizes a study of 87 institutions that have such cooperative technical writing 
programs [5], Manuel-DuPont provides a summary of Writing-Across-Curriculum (WAC) in engineer¬ 
ing programs across the country prior to 1996 [6], Ford and Riley provide a more recent extensive 
summary of programs around North America where communication has been integrated into the 
engineering curricula [7], 

In addition to interdisciplinary communication courses, other techniques have been adopted by 
engineering faculty members to improve technical writing. In an undergraduate laboratory course 
at the University of Nebraska, student peer review was used as a tool to improve technical writing 
skills [8], This study showed that students learned more by critiquing each others’ writing and by 
being involved in the evaluation process. Engineering students at the University of Virginia were 
exposed to the process of scientific peer reviewed publication through peer review of their term 
papers [1], Students carried out a blind peer review of their fellow students’ term papers which 
were written to meet the requirements of a major scientific journal. This approach resulted in higher 
quality final manuscripts, improved grades and provided a better understanding of the peer review 
process to the student. 

Some universities have writing centers where undergraduate and graduate tutors provide help 
to their fellow students by providing feedback on one’s written work [9], However, Mackiewicz 
found that most tutors came from the humanities discipline rather than disciplines which prac¬ 
tice or study technical writing. This posed a strain on the tutor-tutee relationship for engineering 
students due to the informative technical writing style of engineers and persuasive essay writing 
style of the humanities majors [9], To address this disparity, a few institutions have established 
writing centers specifically to meet the needs of engineering students. Interaction between tutors 
and students as well as between tutors and engineering faculty members in these engineering 
focused writing centers has shown promising results [7], 

The question of whether engineering documents are simply informative or are also persuasive 
is debatable. Ford and Teare believe that engineering documents should be both, informative and 
persuasive [2], Winsor studied four engineering co-op students as their writing progressed for five 
years in a work place. She suggests that it is possible that engineers deal exclusively with informative 
writing in early stages of their career, but after years of experience or as they move into manage¬ 
ment, the engineers’ writing evolves into persuasive as well as informative [10], This suggestion is 
supported by Paretti and Burgoyne [11], Interestingly, Winsor also observed in the above study, that 
if students felt the work place practices are different than what they learned in school, they believed 
that the standards of the workplace took precedence over school [10], 

External constituents, such as engineering practitioners, alumni of engineering programs, and 
industrial advisory boards of engineering departments, have participated in technical writing projects 
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for undergraduates [12,13,14], Local professional engineering community has worked with freshmen 
on technical writing courses at the University of California at Santa Barbara and Colorado State 
University [12, 13], A University of South Alabama study carried out in a technical writing course 
compared the perceptions of memo quality by practicing engineers, engineering faculty members 
and freshman engineering students. This study found that students’ and engineers’ opinion of memo 
quality focused more on content and were in close agreement, whereas professors were more criti¬ 
cal on the style of the memo [14], 


TECHNICAL WRITING WITHIN SENIOR DESIGN 


Although there is much written on senior design programs within engineering across the coun¬ 
try, literature focusing primarily on technical writing within these programs is rather limited. At the 
Georgia Institute of Technology Industrial Engineering program, one of the goals was to teach work 
place communication in senior design [15], To achieve the desired goal, the Director of Work place 
Communication who has 20 years of experience identifying communication needs in work place 
co-taught communication with the engineering faculty members. Several chief executive officers 
(CEO), practicing engineers and supervisors of engineers were interviewed to obtain examples of 
written and presented work. From this, a set of criteria for communication excellence in the work 
place was developed and shared with students in senior design. Examples given by the industry 
were made available to the students [15], Brinkman and van der Geest share their experience on 
how various professional engineers who served as clients during the senior design experience re¬ 
viewed the engineering design project documentations prepared by students [16]. They observed 
that although most clients played their role well some clients considered the projects to be “just” 
student projects and, therefore, lauded reports which the faculty felt to be less than professional. 
Industrial advisory boards have been used to review student work in senior design at Louisiana State 
University [17], The advisory board members were interested in the writing skills of their future new 
hires and honestly described the strengths and areas of improvement of student writing. 

Within the capstone course at the University of Utah, the engineering departments partnered 
with consultants from the University of Utah Center for Engineering Leadership, funded by CLEAR 
(Collaboration, Leadership, Ethics and Research) Grant [18,19], While finishing the graduate degrees 
in Communication, Rhetoric and Composition, and English, the consultants worked with engineer¬ 
ing students to improve their writing skills and with engineering faculty members to improve com¬ 
munication within the curriculum. Although the approaches taken differed from one engineering 
department to another, overall they found that CLEAR consultants reduced the faculty workload 
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and were very helpful in improving the writing skills of students [18,19], Other institutions that have 
worked with technical writers have emphasized the importance of a technical writer’s experience 
editing technical documents and familiarity with the design process [20, 21], 

Georgia Institute of Technology and Rose-Hulman Institute of Technology prepare their engineer¬ 
ing students for the senior capstone design technical communication needs in their junior year with 
a writing intensive design course [22, 23, 24], Some institutions have required maintaining project 
notebooks or journals as a medium to encourage informal technical writing among students [11,17, 
25, 26], Ahern and Abbott have developed RedPencil, a software to provide reflective written com¬ 
mentary on multiple drafts of student writing, in senior design [27], 

The case history presented in this paper is different from the above studies in that the Seattle 
University senior design program has encompassed several different constituents (writing center 
student consultants, English department faculty members, technical writers from the industry, and 
practicing engineers) at various times within its twenty year history of the capstone design program. 
Therefore, it is able to make a comparison between the various constituents and their approaches. 
The experience gained, lessons learned, and the assessment and reflection results are useful for 
other senior design programs. 


OVERVIEW OF SENIOR DESIGN PROGRAM AT SEATTLE UNIVERSITY 


Prior to the beginning of school year, the College of Science and Engineering at Seattle Univer¬ 
sity solicits design projects that can be completed within an academic-year from local industries. 
Teams of three to four students work under the direction and supervision of a company liaison and 
a faculty advisor to solve a real life engineering problem. Gnanapragasam describes the details of 
the implementation of the senior design program within the Civil Engineering Department at Seattle 
University [28], 

The fall quarter is spent meeting with the company liaison(s) and the faculty advisor, visiting the 
project site (if applicable), understanding the overall goal of the project, brainstorming ideas for 
solving the problem, and defining the scope and final project deliverables. This preliminary work 
results in a written proposal which is submitted to the sponsor at the end of November. The students 
spend winter and spring quarters working on the project. The project culminates in spring with a 
written final report to the sponsor. 

The proposal covers the project background, problem statement, project objective, scope of 
work, plan of implementation (task breakdown and deliverables at the completion of each task, if 
applicable), project schedule, budget, references and bibliography and resumes of team members. 
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The final report consists of project background, team’s solution to the problem, external constraints 
controlling the design (such as political, social, economic and ethical issues), relevant calculations, 
engineering drawings (whenever applicable), conclusions and recommendations to the sponsors. 
Sample proposals and reports can be found at <link here>. 


DEVELOPMENT OF TECHNICAL WRITING COMPONENT 


Several constituents have contributed to shape the technical writing component of the capstone 
experience over the years. Figure 1 shows the major constituents, namely the Seattle University 
English department, the technical writer from the industry, adjunct technical writing instructor, the 
industrial advisory board and the civil engineering faculty members, and their period of involvement. 
The next four sub-sections describe the civil engineering faculty collaboration with the other four 
constituents in molding the technical writing component over the past 20 years. 

a) Collaboration with the English Department 

Since the inception of the design program, the engineering faculty members have worked with the 
English department faculty members to develop strategies to improve the quality of the proposals 



Figure 7; Constituents Contributing towards Technical Writing. 
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and final reports. Their collaboration resulted in the development of a set of writing guidelines for 
the proposal as shown in Appendix A [29], These guidelines provide: 

i) templates for proposals which teams customize as needed, 

ii) explain the purpose of each section, 

iii) discuss the audience for the document, and 

iv) provide formats for citing references such as books, journal articles, maps, reports, personal 
communication, and websites. 

Furthermore, the faculty members developed a scoring rubric that is used by various constituents 
to assess both the documents. The writing guidelines have undergone several revisions over the 
years. Copies of the writing guidelines are made available to the students and faculty advisors at 
the beginning of the academic year. This document does not in anyway look like or replace a text 
book on technical writing. However, it brings a degree of uniformity to the documents prepared by 
the various engineering disciplines, while allowing flexibility to customize the documents to meet 
client needs, and helps the students to understand the expectations of the written documents. 

In the early years of the capstone program, an English department faculty member who has a 
passion for technical writing gave a few lectures on technical writing to the senior design class in 
early fall quarter. In 1998 the lectures were replaced with workshop sessions during which students 
wrote various parts of a proposal in a team setting. With time it evolved into a system where each 
design team (a total of 20-25 teams from electrical, civil and mechanical engineering) submitted a 
pre-selected portion of the proposal (e.g., introduction or list of references) to the English depart¬ 
ment faculty member prior to a class meeting. The instructor reviewed the write-ups before class 
and used the class time to critique them. He projected a few of the writing pieces on the screen 
and discussed their strengths and weaknesses and how to improve it. These sessions were helpful 
to see where information was unclear or lacking to a reader who was unfamiliar with the project. 
However, the drawback to this approach was that there was not enough time to go over the work 
of all teams within the short time span. Due to cost consideration, the English department faculty 
member could spend only limited amount of time in fall quarter and could not extend his services 
for other quarters. 

Seattle University has a Writing Center that is run by an English department faculty member. 
Students who exhibit strong writing skills from various departments are hired as writing consultants. 
These students have a diverse background but none are science or engineering majors. They hold 
office hours to help students with various writing assignments. Writing consultants who have an 
interest in technical writing were chosen and assigned to engineering design teams to review and 
critique project documents. These writing consultants were coached by the English department 
faculty member on technical writing and were familiar with the set of writing guidelines discussed 
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previously. Each senior design team was assigned a writing consultant for a whole academic year. 
Design teams were required to submit their work at various stages to their writing consultant for 
feedback. This system did not work well for many reasons. The writing consultants wanted several 
days, sometimes weeks, of advanced notice on when the drafts would be turned in for review. Being 
students themselves, the consultants did not want the reviews to interfere with their own course 
work. They typically needed several days to review the document. The engineering students were 
trying to balance their course loads, work outside of school, sponsor needs and the tight project 
deadlines. Therefore, they needed the writing consultants to review the document at short notice 
and expected the reviews to be performed quicker. Furthermore, there was conflict between the 
engineering teams and non-engineering writing consultants on the genre of technical writing for 
engineers. Engineering students felt that their technical reports should be informative and that their 
audience needed to be familiar with basic engineering terms. However, the student writing consul¬ 
tants were more used to persuasive essay type writing and felt that all engineering terms, however 
basic, should be explained in detail. Therefore, after several years of trial and sincere attempts by 
faculty members from both departments (engineering and English) to make this collaboration work, 
the design team-student writing consultant partnership was suspended in 2004 by all engineering 
departments. 

b) Collaboration with Industry through a Technical Writer 

In 2003-04 academic year the English department faculty member who was conducting the 
technical writing sessions for senior design took a sabbatical leave. The engineering departments 
decided to explore a new approach to senior design. A technical writer from a local civil engineering 
consulting firm was willing to volunteer her time to review the proposals and provide feedback. Pro¬ 
posals were submitted to the technical writer in two instances: once at an early stage of development 
of the proposal and next at a more mature stage of the proposal. She reviewed the proposal drafts 
prior to the class meetings. On the day of the class session, she projected selected proposals on 
the screen and critiqued them. Although the technical writer did a fine job reviewing the proposals, 
coming from industry she did not hesitate to harshly criticize poor or unclear writing. It was a rude 
awakening to the students who are not used to such criticisms from faculty members. 

Students were surveyed twice, once in the middle of the fall quarter and then at the end of the fall 
quarter, to get feedback on the effectiveness of having a technical writer review the proposals. The 
middle of the quarter survey showed that the students were very unhappy with the technical writer 
and perceived it as a negative experience. Students did not like the technical writer projecting their 
work on the screen and critiquing. Some students felt that because the technical writer came from 
a civil engineering consulting firm she did not understand electrical and mechanical engineering 
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projects. However, the end of the fall quarter surveys showed that most felt that having a technical 
writer was effective and resulted in a better proposal at the end. 

c) Hiring of a Adjunct Technical Writing Instructor for Subsequent Years 

In 2005, the project center decided to hire an adjunct technical writing instructor to assist in 
the proposal preparation. This technical writer had a science background and had prior experience 
working as a technical editor. She spent an hour every week with each of the three engineering 
disciplines (Civil and Environmental, Mechanical and Electrical) throughout the fall quarter. 

The first year, fail 2005, the adjunct instructor had a series of lectures on technical writing fol¬ 
lowed by feedback sessions critiquing student proposals. The department followed the same format 
for the proposal reviews as previously discussed with the technical writer from industry. Students 
submitted parts of their proposal to the adjunct instructor prior to class several times during the 
quarter. The instructor reviewed the submittals and critiqued the civil engineering projects during 
class time. Again, the students were horrified when their work was projected on the screen and 
critiqued. Student feedback on having an adjunct instructor review their proposals was quite similar 
to the ones received the previous year with the technical writer from industry. 

In 2006 the Electrical Engineering department decided to discontinue the services of the techni¬ 
cal writing instructor as it felt it was not beneficial to their students. The faculty advisors and the 
departmental project coordinator were responsible for reviewing and providing feedback to the 
teams within their department. Civil and Environmental and Mechanical Engineering departments 
continued working with the technical writing instructor. 

Starting fall 2006 the Civil and Environmental and Mechanical Engineering departments changed 
the format of the critiquing sessions. Student teams submitted parts of their proposal to the ad¬ 
junct instructor. A day or two following the submittal, individual critiquing sessions were scheduled 
between the instructor and each team. Each review session with a team typically lasted about half 
an hour. The faculty advisor was required to be present at these sessions during the early stages 
of the proposal. But once the proposal started taking shape the faculty advisor was not required 
to attend. Feedback from teams on this arrangement has been overwhelmingly positive. Students 
did not mind harsh criticism of their writing from the instructor within their own team setting. The 
presence of the faculty advisor at the meeting helped answer questions that students could not 
handle. This format has been in effect in Civil and Environmental Engineering till now (fall 2009). 
The technical writer did not work with the Mechanical Engineering department in fall 2009 due to 
prior commitments but plans to return in fall 2010. 

Due to cost issues the adjunct instructor could not be hired to review the final reports in spring 
quarter. However, students expressed that multiple proposal review sessions between the teams 
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and the writing instructor in fall quarter helped improve their technical writing skills and gave them 
confidence writing the final report. 

d) Input from the Industrial Advisory Board 

In addition to the above constituencies, the Department of Civil and Environmental Engineering 
uses its industrial advisory board to review the proposals and reports. Mechanical Engineering does 
the same with its advisory board while Electrical Engineering does not. The discussion in this sec¬ 
tion is restricted to the experience of the Civil and Environmental Engineering with its departmental 
industrial advisory board. 

For the past decade the Civil and Environmental Engineering department has had an active in¬ 
dustrial advisory board consisting of about ten practitioners. The board meets quarterly to discuss 
curriculum, student recruitment/retention and senior design project issues. A subcommittee of four 
members with diverse civil engineering background (environmental, geotechnical, structural, and 
water resources) provides feedback and evaluates the written proposals and final reports. 

The proposals and final reports are sent electronically to the subcommittee when the documents 
are near completion. The subcommittee members spend about a week to review the documents 
and provide written feedback on strengths and weaknesses of proposal/report, areas of improve¬ 
ment, technical deficiency and clarity of the document. They also evaluate the documents using 
the scoring rubrics developed by the faculty. The most current versions of the rubrics used by the 
Department of Civil and Environmental Engineering for the proposal and the final report are pre¬ 
sented in Appendices B and C, respectively. The student teams address these comments before 
finalizing the project documents. 

The students took the comments from the industrial advisory board much more seriously than 
those from other reviewers (faculty members, technical writer and student writing consultant). For 
example, suggestions, sometimes made several times by the faculty members and technical writer 
on the clarity of a figure or formatting of a table, were ignored completely by the students. How¬ 
ever, when the same suggestions were subsequently made by an industrial advisory board member 
they were attended to immediately. It is possible that the students treat these practitioners more 
like their future employers and want to impress them with good quality work. The above observa¬ 
tion supports Winsor’s speculation that students are more responsive to an audience whom they 
perceive to be more powerful [10], This speculation is applicable to senior design, as the students 
are close to graduation and are looking for employment. Therefore they consider practitioners to 
be more important than other reviewers. 

This program’s long term success has been due to the dedication of a core group of subcommit¬ 
tee members. We have had some practitioners join the subcommittee but quit shortly thereafter 
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due to the fact that they could not find the time to review the documents in their busy schedules. 
Planning the dates for the reviews well in advance with the subcommittee, at the beginning of the 
quarter, has been helpful for a timely review. 


ASSESSMENT, REFLECTIONS AND PERCEPTIONS BY THE CONSTITUENCIES 

Proposals and reports have been assessed by civil engineering faculty members, industrial 
advisory board and project sponsors over several years. Reflections of industrial advisory board 
members on the quality of writing, numerical assessment of documents by project sponsors, survey 
results of seniors and alumni on how well they were prepared in the area of technical writing are 
presented below. 

a) Assessment by Civil Engineering Faculty Members and Industrial Advisory Board 

For the past nine years, the proposals and final reports have been evaluated by the industrial 
advisory board and the civil engineering faculty members. The proposals and reports are evaluated 
on a scale of 1 (poorly written) through 6 (well written) using the detailed scoring rubric described 
previously and the most recent version of which is presented in Appendices B and C. 

Each year the scores of the faculty panel and the industrial advisory board for the proposals and 
final reports are compared and discussed at departmental faculty meetings. The faculty panel has 
changed over the years due to retirement and hiring of new faculty. The industrial advisory board 
membership changes every three years. The scoring rubric is revised periodically to meet the current 
needs. Because the panel of reviewers and the scoring rubric have changed over the years it is hard 
to find any trend in the numerical scores of the two entities over the past nine years and therefore is 
not presented in the paper. Nevertheless, it is worth sharing the written quotes and criticisms from 
the industrial advisory board members from recent years. 

"/ was very impressed with the quality (sic: of the documents) this year. / think it is evidence 

of good students and good teachers." (from 2003) 

“The reports are very impressive and the school should be proud of the job you do." (from 

2004) 

“The one thing I noticed with all of the proposals is weakness in the letter of transmittal. 

These tend to be quite bland & contain empty, unproven claims or general assurances. 
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This is eerily similar to what / see from many consultants in their marketing materials - so 
the students are not alone in this situation. There was one sentence that appeared in each 
letter that / found particularly unhelpful without greater explanation. It is the one that reads 
“Our process will meet all of the standards and regulations ... ” or “Our plan will meet all of 
the requested deliverables..." or "Our plan will meet all of the specifications...". This is sort 
of like saying ‘we will do a good job’, without actually providing any reason to believe that 
claim. And then the reader starts to wonder...will they do a good job? / think it is better to 
just demonstrate the fulfillment of the requirements than promise to do so." (from 2006) 

"A tremendous amount of effort and application has gone into this project and the high 
quality of the report reflects that. Congratulations!" (from 2007) 


b) Assessment by Industry Sponsors 

Since 1995, at the end of each academic year, the College of Science and Engineering has sur¬ 
veyed the sponsoring entities to assess the overall project success and sponsor satisfaction. As part 
of the survey, the sponsors are asked to rank the quality of the report on a scale of 1 through 5 (1 
- poor; 2-below average; 3-average; 4-good; 5-exceptional). Figure 2 shows the average rankings 
of the reports by sponsors over the past several years. 

Although no clear trends can be seen from one year to another, Figure 2 shows that sponsors 
have considered the final report to be good-exceptional 58% of the time and average-good 42% 
of the time. 



(7) (8) (7) (5) (3) (4) (5) (5) (5) (5) (6) (6) 


Year 

(no. of projects) 

Figure 2: Evaluation of the Final Report by Project Sponsor (Ranking on a scale of 7 (poor) 
through 5 (excellent). 
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c) Reflection by Students and Alumni 

Since 2002, the College of Science and Engineering has been surveying the seniors close to graduation 
to assess their preparedness to enter the workforce. As part of this survey, students are asked to rank, 
on a scale of 1 through 5, the importance they feel communication skills will have in their professional 
lives and the preparedness they feel they received from the program. Table 1 summarizes the results for 
the period from 2002 through 2009 for the civil engineering seniors. It shows that students recognize 
the importance of communication skills in the work place and feel they are adequately prepared. 

Since 2001, every three years, the College of Science and Engineering has been surveying its 2, 
5 and 10 year alumni to assess how well Seattle University has prepared them for the workforce. 
Alumni are asked to rank the importance of communication and the preparedness they received at 
Seattle University. These results are presented in Table 2. 

Although Table 2 shows that alumni recognize the importance of technical writing, the survey 
results are somewhat inconclusive due to the low response rate ranging between 17 and 33%. For 


Year (population size) 

Importance (I) 

Preparedness (P) 

P/I 

2002 (20) 

4.40 

4.13 

0.94 

2003 (8) 

4.94 

4.16 

0.84 

2004 (13) 

4.85 

4.15 

0.86 

2005(17) 

4.82 

4.21 

0.87 

2006 (22) 

4.45 

4.13 

0.92 

2007 (20) 

4.80 

4.35 

0.91 

2008(17) 

4.82 

4.47 

0.93 

2009(19) 

4.79 

4.42 

0.92 


Ranking on a scale of 1 (low) - 5 (high) 


Table 1: Student Perception of Importance vs. Preparedness to Communicate Effectively. 


Graduation Year 

Importance 

Preparation 

P/I 

1990 

4.83 

4.17 

0.86 

1992 

4.50 

3.69 

0.82 

1994 

4.54 

3.50 

0.77 

1995 

4.81 

3.77 

0.79 

1997 

4.69 

4.28 

0.91 

1999 

4.79 

4.13 

0.86 

2001 

4.79 

3.88 

0.81 

2003 

4.45 

4.45 

1.00 

2004 

5.00 

4.00 

0.80 

2005 

5.00 

3.50 

0.70 

2006 

5.00 

2.00 

0.40 


Table 2: Alumni Reflection of Importance vs. Preparedness to Communicate Effectively. 
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example, in Table 2 only one 2006 graduate responded to the survey. However, the student exit 
survey results presented in Table 1 is much more conclusive due to the 100% response rate. 


LESSONS LEARNED FROM THE DIFFERENT APPROACHES 


We have learned several lessons about technical writing within senior design from the multiple 
partnerships we have had over the years. The important lessons are summarized below. 

• The writing guidelines developed in partnership of the English department have been extremely 
useful in conveying the expectations for the proposal and the final report. It also has brought 
some degree of uniformity in the document across the various engineering disciplines. 

• Writing center student consultants who review technical writing should be familiar with the 
engineering writing genre. Unless the student consultants have either had experience writing 
such documents or have been trained by experienced technical writers, it is difficult for them 
to serve as effective reviewers. 

• It is advantageous to have external reviewers, such as professional technical writers and en¬ 
gineering practitioners, review the student documents. Faculty advisors and project liaisons 
are far too familiar with the project. Therefore when reviewing student documents they tend 
to fill in the missing pieces of information in their mind. 

• The writing instructor meeting with individual teams for reviews resulted in better tutor-tutee 
relationship than critiquing a team’s writing in front of the whole class. The former practice 
also resulted in a better final product. 

• Senior design programs need to budget the time of a technical writer if they are considering 
hiring one. Thorough review of a technical document takes time and a person carrying out 
these reviews should be compensated. 

• Students, in general, are more responsive to the comments made by the professional engi¬ 
neering community than that of faculty members. They consider the professional engineers 
to be prospective employers. 

• Review of documents by the professional engineering community requires detailed coordina¬ 
tion. Dates for reviews should be picked well in advance (at the beginning of the quarter) so 
that they do not conflict with travel plans and/or other project deadlines of the practitioners. 
The large file sizes of the project documents have posed difficulty in sending them electroni¬ 
cally. This problem was circumvented by setting up remote FTP (file transfer protocol) server 
that can be accessed by both the design coordinator and the practitioners. 
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SUMMARY 


Seattle University’s senior design program has partnered with various internal and external 
constituencies to improve the technical writing skills of the students. English department faculty 
members and students, technical writers with industrial experience, and the professional engineering 
community have worked with the engineering departments to help shape the writing component 
within the senior design experience. Important lessons learned over the 20 years are that reviewers 
should have a technical background to review engineering document and professional engineers 
bring added value to the review process and better student responsiveness to comments. Assess¬ 
ment results and reflections by the constituencies indicate that the graduates continue to acquire 
the communication skills needed in the profession. Though it is not conclusive as to which meth¬ 
odology works best in teaching technical writing, the key is for the engineering programs to make 
a reasonable effort in teaching students technical writing. It is hoped that the information from the 
past 20 years will be helpful to other senior design programs. 
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I. WHAT IS A PROPOSAL? 


Proposal writing is one of the most important components of success in engineering and com¬ 
puter science careers. It is an engineering and computer science firm's main marketing tool. When 
prospective clients need engineering and computer science services, they distribute a Request 
for Proposal (RFP) inviting engineering and computer science firms to compete for the job. In its 
proposal, the engineering and computer science firm explains its proposed solution to the client’s 
problem, shows why the solution will be effective, and specifies costs and fees. Most engineering 
and computer science projects originate with a proposal of some kind. Once a proposal is accepted 
by a client, it becomes a crucial legal document. It ensures that both the engineers and the client 
agree on the scope of work to be performed (the deliverables to be provided, the documents to 
accompany the deliverables, and so forth), the criteria that must be met, the timeframe for complet¬ 
ing the project, and the costs and fees to be charged. The document also specifies what resources 
the client will provide the engineering and computer science team. 


II. FEATURES OF A GOOD PROPOSAL 


A good proposal demonstrates understanding of the client’s problem, recognizes the client’s 
needs and constraints, and persuades the client that the solution being proposed is effective and 
cost-efficient. 

• The proposal markets your services and ultimately sells you to your client. Because its purpose 
is to obtain clients, a proposal is a marketing document, not an educational piece. Proposals 
should convince clients you have a workable plan to solve their problem. 

• A good proposal is clear, concise, and direct. It should be understandable to an educated 
layperson. Non-technical managers, as well as specialized engineers, normally make decisions 
on proposals. 

• The proposal should look professional, but not slick. “Professional” means complete and well 
thought through so that the proposal models the excellence you will bring to the project. 

• The proposal should reflect your client’s view of the world—use terminology familiar to the 
client. Try to write the proposal from your client’s frame of reference. 

• To the extent possible, the client should be involved in preliminary discussions so that the proposal 
is tailored to the work to be done and to the specific needs of the sponsor’s organization. 

• The proposal should clarify the problem. What is the background on the issue? What has been 
published in the professional literature that has bearing on your design problem? 
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• The proposal should clarify the unique features that your team brings to the project—both the 
unique features of your design approach and the particular skills of you and your team. Your 
client must have a clear image of you in relation to your competition. What is it that you will 
bring that others will not? 

• Typically, the proposal should describe and evaluate several alternative design approaches 
and show why the chosen approach is superior to the alternatives. Likewise, winning proposals 
typically review available literature on the problem. 

• The proposals should use visuals effectively by including only those that are necessary, by- 
referencing them accurately, by labeling them clearly, by explaining them fully in the text, and 
by avoiding “bells and whistles.” 

• The proposal should be flawlessly written and edited. If possible, have someone with no vested 
interest in the proposal read the document before you send it off. At Seattle University this 
may be a Technical Writer/Writing Center consultant, but in professional life you would find 
an outside reader who could read the whole document with fresh eyes. 

• The proposal is specific and complete. The Scope of Work section clearly specifies what you 
will do for the client. The Plan of Implementation section clearly shows the sequence of tasks 
that must be accomplished to provide the completed work product. 

In developing your proposal, ask yourself the following questions: 

• Is your proposed design a good one? Why? Are you solving the client’s problem in an efficient, 
cost effective manner? 

• What “agendas” does the client organization have? Do your homework about your client’s real 
needs. Why do they need the problem solved? How does this problem relate to other issues in 
the sponsoring company? What are the criteria on which your proposal will be judged? What 
“point system” will your client use in evaluating your proposal? Are preferences given to one 
approach rather than another? 

• Who are the key players in the client organization? Who will ultimately make the decision? 
Is it a single individual? A panel? What kind of command chain does the proposal have to go 
through to be signed off? 

• What timelines must be met? What problems are you apt to confront that may force you to 
miss a deadline? Have you planned for contingencies? Where might you foresee cost overruns? 
Is your budget realistic? 

• What will the client provide? The proposal should document what the client will do — 
what the client’s resources and support will be. For example, if the client will provide 
an office or telephone system or a special computer—all this should be detailed in the 
proposal. It is amazing how many things that you are sure someone promised get lost, 
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forgotten, or ignored in the transition from concept to implementation—without a con¬ 
crete proposal. 

The department coordinator will share sample proposals that are appropriate for your field. 


III. ORGANIZATION OF THE PROPOSAL 


This section provides a structural template for an engineering or computer science proposal. Note 
that a proposal includes front material (cover sheet, letter of transmittal, title page, summary/abstract, 
table of contents, list of figures, and list of tables), the main body of the proposal, and appendices. 
The first three parts of the main body (introduction, scope of work, and plan of implementation) 
demand the most writing effort. 

Note that each section of the proposal has a specific purpose. All team members should under¬ 
stand the purpose of each section and put material in the right section. Make sure that the readers 
can tell a section’s purpose from cues in the writing. 

The text itself should read like an argument with an easy-to-follow structure complete with tran¬ 
sitions, a clearly stated point for each paragraph, and appropriate details supporting each point. 
Headings and subheadings are there only for the reader’s quick visual orientation. The document 
should read smoothly and clearly with all the heads removed. Try to imagine writing the proposal 
without any headings whatsoever so that you are forced to include sufficient transitions. Then add 
the headings back in. 

All figures and tables must be clearly referenced in the text and explained in detail. Imagine each 
figure projected on a screen during an oral presentation. Typically you would talk your listeners 
through the figure using a pointer. The text of your proposal should do the same thing. Figures and 
tables are not self-explanatory. You must tell your readers what you want them to see or under¬ 
stand. 

The following outline (section A) is based upon typical proposals in technical fields. In section B, 
each part of the proposal is discussed. In particular, the sections in the main body labeled ‘Scope 
of Work’ and ‘Alternative Solutions and Evaluations’ are expanded in several ways that reflect the 
nature of the original Statement of Work received from the client. Proposals are tailored to specific 
situations and some discussion and examples are given to help you discern which format may be 
most appropriate for your project. 
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A. Outline of Contents for the Proposal 

Your proposal should contain the following parts or sections: 

Cover 

Letter of Transmittal 

Title Page 

Table of Contents 

List of Figures 

List of Tables (if relevant) 

I. INTRODUCTION 

A. Background 

B. Statement of the Problem 

II. SCOPE OF WORK* 

A. Overview 

B. Literature Review 

C. Alternative Solutions and/or Evaluation (see instructions) 

D. Decision 

III. PLAN OF IMPLEMENTATION* 

A. Research 

B. Design 

C. Prototype Construction (if relevant) 

D. Testing 

E. Documentation 

IV. REFERENCES AND BIBLIOGRAPHY 

V. FACILITIES 

VI. PERSONNEL/ORGANIZATION CHART 

VII. SCHEDULE 

VIII. BUDGET 

Appendices (list each appendix in the table of contents) 

Appendix A - Statement of Work or RFP 
Appendix B - Student resumes 
Appendix C - Previous work done by team 

•Sections II and III may be customized for each project. You could discuss this with your faculty 
advisor, sponsor or your design coordinator for suggestions. 
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B. Explanation of Each Section of the Proposal 

This section explains the purpose and contents of each section of the proposal. In preparing your 
proposal you should use the style guidelines for headings in section IV.B. These style guidelines are 
also illustrated in the way this material is presented in the body of the proposal. 

7. Front Material 
Cover 

The cover for your proposal should look like that of the attached model proposal. 

Letter of Transmittal 

The proposal is introduced to the client through a “letter of transmittal”—a brief one-page business 
letter addressed to the liaison at the sponsoring company. The letter explains that the requested 
proposal is attached. Summarize your proposal briefly and highlight what you see as its major sell¬ 
ing points. This letter constitutes your reader’s first impression of your team—its professionalism, 
thoroughness, and writing ability. Make the letter graceful, respectful, and professionally cordial; use 
the letter to sell your design approach and your team’s abilities. The letter of transmittal is often the 
last part of the document you write, but save plenty of time to write a good one. 

Title Page 

The title page for your proposal should look like the example in the model proposal. 

Table of Contents, List of Figures, List of Tables 

Any proposal of more than five pages should have a Table of Contents. The Table of Contents 
should include all the main headings in the proposal, showing page numbers. Teams should make 
sure that headings in the Table of Contents are worded exactly as they are worded in the proposal 
itself. Following the Table of Contents are a List of Figures and a List of Tables (the figures and tables 
themselves are embedded in the text). Include only necessary figures and tables that contribute to 
the reader’s rapid comprehension of material. Several figures common to most proposals would be 
an organization chart and a project schedule. Proposals that evaluate various alternative solutions 
would include a decision matrix. 

2. Body of the Proposal 

The following pages contain a template for the sections of the body of the proposal. Each sec¬ 
tion is shown with the appropriate level of heading as illustrated in section IV.B. on page 16. A box 
is used to simulate the pages of your proposal document (do not put a box around the narrative 
in your proposal). 
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I. INTRODUCTION 

The Introduction is the first section in the main body of the proposal. As such, it is headed 
with a First Level Heading. At the start of the Introduction, provide an overview of the whole 
proposal in one or two sentences. Use the following wording: 

This proposal responds to a Request for Proposal from [.sponsoring company] [include 
date, if known, or title of RFPJ. The [sponsoring company] seeks a solution to the [describe 
the problem to be addressed]. The [sponsoring company] requests [describe the main 
deliverables the sponsor expects.] 

The Introduction includes a statement of the problem along with necessary background 
information. Describing the problem to be solved is important in both solicited and unsolicited 
proposals, even though the writer knows that the recipients understand their own problem. 
In solicited proposals, the problem statement shows that the writer, too, understands the 
problem and has the readers’ concerns in mind when setting forth a solution. In unsolicited 
proposals the writer often needs to convince the reader that the problem exists. In some 
proposals the background information and statement of the problem have their own sub¬ 
heads. In other proposals, the background information is woven smoothly into the statement 
of the problem. 

A. Background 

To provide a context for the reader, the writer often needs to supply background information 
about the company and the history of the problem to be solved. Organizationally this section 
is headed with a Second Level Heading. 

In the background section the conditions leading up to the problem are described, indicating 
why the problem is now being considered and why it is important to the company. If previous 
attempts at solution have been made, they are described along with their results and shortcom¬ 
ings. A brief review of the literature is sometimes given at this point. Often a better place to 
put literature review is in the Scope of Work section as an introduction to Alternative Solutions. 
What the writer needs to show is an understanding of the total context of the problem and an 
awareness of previous work in the area. 
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B. Statement of the Problem 

The team spends a paragraph to several pages defining the problem, its significance, its 
ramifications, and its relation to larger problems or issues. The team must also identify the 
specifications, criteria, and constraints described by the sponsor in the RFP. By the end of the 
introduction the reader knows what the problem is, why it is important to the sponsor, why it is 
problematic technically, and what specifications and criteria a suitable solution must meet. 

II. SCOPE OF WORK 

This section summarizes what the project team actually proposes to do. Usually the Scope of 
Work involves several stages with different goals for each stage and ends in some kind of final 
product. This section differs from the Plan of Implementation in that the Plan of Implementation 
section focuses more on the “how we will do it” rather than “what will we do.” 

A. Overview 

The Overview section of the Scope of Work should summarize what the team will do for the 
project and specify deliverables. Often work will be divided into several stages such as a research 
stage, a design stage, a construction stage, and a final testing/calibration stage. These stages 
should be specified and described briefly in the Overview section to provide a clear statement 
of all the work to be done. You will need to work cooperatively with your faculty project advisor 
and sponsor liaison, who must approve your design plan. 

B. Literature Review 

To keep from re-inventing the wheel and to be professionally aware of the state-of-the-art 
on any design question, effective engineers and computer scientists search and review the 
available literature and intellectual property before tackling a design problem. What has been 
published in the professional literature that has bearing on your design problem? In this sec¬ 
tion, discuss those items you have found in the professional literature that have influenced your 
thinking about the project. You may have found an article that virtually outlines the solution to 
your project in full, there may be another source that created an interesting idea in your mind 
about how to handle part of the design, or there may be a web site that illustrates unfortunate 
consequences (for your situation) of using a particular design approach. All of these should 
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be reported, since they had an effect on your evaluation of how to proceed on the project. You 
may also mention sources you have not had time to evaluate in full, but you plan to use heavily 
in your design work. You should have enough familiarity with such works to explain what role 
you expect they will have. A literature review is not supposed to be a grab bag of somewhat 
random items intended only to impress the reader. 

For instance, suppose that your team were to design a handheld data-acquisition and display 
unit for use in automotive repair shops. During research, you have discovered there are several 
data paths built into modern engines and that descriptions of the data contents and format 
can be found in certain key standards documents. You have also found that an alternative 
to designing a small handheld device from scratch exists: several Personal Digital Assistants 
(PDAs) have an external port for interacting with a variety of other equipment. A specification 
of such a port has been also located. Thirdly, you have found articles discussing special design 
techniques to ensure accuracy when sampling data in electrically noisy environments. All of 
these relevant items can be incorporated into a useful literature review, the relevant part of 
which might read: 

“It was initially expected that a separate probe point would have to be established for each 
data type examined within an engine, and these points would vary from engine type to 
engine type. The Society of Automotive Engineers (SAE) has established a standard for a 
data bus upon which various data types may be multiplexed 1 . It is anticipated that several of 
the required data types will be captured with a single connection to this bus. The standard 
also specifies the type of connectors to be used in accessing this bus. 

“One design approach for this device would be to design a microprocessor-based system 
with the appropriate memory and peripherals for the task. However, several commercially 
available Personal Digital Assistants (PDAs) come with a standard external port 234 for 
connection to various accessories and third-party devices. Casio, in particular, publishes a 
specification 5 for their external port that encourages other vendors to develop supporting 
hardware for their devices. This may prove to be a significant savings for the project. The 
analog-to-digital conversion circuitry may be purchased ready-made or designed by the 
team. An article by Jim Williams 6 discusses several key design techniques necessary for 
data acquisition in an electrically noisy environment, which is an apt description for the 
electrical system for an automobile. Any purchased circuit would need to be evaluated 
relative to these issues, as would any designed circuit.” 
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If the company requests an innovative solution from your design team, you may need to search 
for and understand already patented design solutions. Usually a search through the US Patent 
Office should suffice. The Literature Review Section of your report is a logical place to report 
on results of your search. While reporting, you need to show how the cited patents pertain to 
your design. You may need to explain how each design you found is different than your design, 
to assure the reader that you are not replicating the patented design, but you may also discuss 
similarities that may have sparked your design solution. 

C. Alternative Solutions and Evaluation 

The next sections are a bit flexible, depending on the nature of the design. When clients 
issue a Statement of Work, there is enormous leeway in how carefully various aspects of the 
statement are specified. As your design team strives to understand the client’s needs, develop 
a design plan, and write a proposal that addresses those needs, different formats for that pro¬ 
posal may be appropriate. In the following, we will lay out four basic styles in the Statement of 
Work, discuss some possible motivations for their having been written in that way and ways to 
write this portion of the proposal to best assure the client that your team has a good handle on 
how this design effort should proceed. Let’s look at some scenarios. 

1. The Broad Statement Of Work 

The Statement of Work may carefully describe what the final product or process is to ac¬ 
complish. This may come in the form of performance specs, look-and-feel issues, and/or eco¬ 
nomic issues. These specifications may place a large number of constraints on the final choice 
of design approach, but the statement focuses only on the output and not on the path to get 
there. It may be that the client knows what is wanted, but does not care to specify the means. 
This could be because the client does not have any clear ideas of how the problem can be 
solved, or perhaps the client is interested in seeing a new approach. It could be that the client 
is pretty certain there is only one viable approach to solving this problem and wants to see if 
the contractor bidding on this problem is smart enough to see that. 

Let’s look at an example. The Statement of Work reads: 

“The XYZ Truck Company is exploring how tractors and trailers can be better integrated to 
improve fuel economy. At 60 mph, aerodynamic drag accounts for over 50% of the vehicle’s 
total fuel consumption. Air gaps between the tractor-trailer combination allow the air to 
become unsteady and create additional drag. Cab extenders at the rear of the tractor and/ 
or the sleeper are designed to reduce this effect. However, there are practical constraints 
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limiting the length of the cab extenders since adequate space between the tractor and 
trailer is required for articulation at low speeds. The contrasting requirements of the gap 
space provide an opportunity to develop an innovative solution for optimized tractor-trailer 
integration. 

“The objective of the student project is to demonstrate a functional prototype of a dynamic 
self-adjusting cab extender with the purpose of improving heavy-truck fuel economy. 
Dynamic self-adjustable cab extenders will serve as a gap sealer and airflow management 
device at high speeds and provide the necessary clearance for articulation at low speeds. 
Target costs will be developed by XYZ to guide the engineering students and ensure the 
proposed design is marketable.” 

The statement makes it clear what the client is looking for and why. But it has not said any¬ 
thing about what the form of this cab extender should be and what kind of technology should 
be used to make it respond dynamically to changing conditions. It is in the interests of the client 
for the team to consider more than one possible solution and estimate which is best. 

In this case, there should be a section for presentation of the alternatives to be considered 
for the design approach. This is where you explain different approaches your team could take, 
describing each approach and analyzing its strengths and weaknesses in terms of technical 
and economic feasibility. 

Then a section that evaluates these alternatives is next. In this section you describe the criteria 
you used to evaluate the design approaches and justify the weights you give to each. Discuss 
external constraints including economic, environmental, sustainability (e.g., long term availability 
of parts, equipment, or staff to continue the processes), manufacturability, ethical, health and 
safety, social, and political constraints. Frequently this section will refer to a decision-matrix figure 
that displays each of your criteria, assigns relative weights to them, and scores each alternative 
against each criterion in turn. This section talks your reader through the decision matrix. 

In most cases, you should consider it your goal to have done the evaluation of the alternatives 
and be able to make a clear choice at the time of the proposal. The client likes to see evidence 
of a well-focused design team. To analyze a number of design alternatives and evaluate them 
well usually requires some preliminary design work. Don’t fall into the thinking that design 
begins only after the proposal is written. Writing a good proposal involves enough initial de¬ 
sign work under alternative approaches to make an educated evaluation. Make clear summary 
statements about the strong points of your chosen design approach and the weak points of 
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rejected alternatives. If there were really other design groups trying to win a bid for the right 
to design the product, they may be promoting other design approaches. It helps to point out 
the weaknesses of other approaches. 

2. The Specific Statement Of Work 

In this type, the desired output is specific, and the path is significantly laid out as well. The 
statement may, for example, specify that a particular microprocessor or software language be 
used. There may be a variety of reasons that a client would be so directive in the Statement 
of Work. Perhaps the client is specifying a technology they have confidence in, because of 
prior experience. When the company absorbs the design output of the team, there will be no 
new learning curve due to unfamiliar technology. Alternatively, the client may recognize that a 
thorough analysis of design alternatives is a huge task, and is trying to cut through to an earlier 
design start. 

As an example, consider the following: 

“The Generic Integrated Circuit Company designs full-custom modules of specialty memory, 
including those with two ports, one to read from and one to write to. Problems can occur 
when the memory is being read from faster than it is being written to or viceversa. Flag 
logic can solve this problem by disabling either the write or read signal, depending on the 
situation. Dual clocks are used for read and write functions. A dual clock, two-port, first- 
in/first-out static memory will be designed and simulated according to a set of design rules. 
Those rules include development being done with the Tanner Tools 1C design software 
suite, producing integrated circuit modules that conform with the module format of the 
company’s commercial library of 1C modules.” 

Here the company has suggested ways to solve the common design problems encountered 
in this kind of design and has specified the development tool to use and the format of the final 
product. It is apparent the goal is to expand their library of component offerings with this new 
FIFO memory, giving them a competitive edge. 

In this context, presenting an extensive section on alternatives and another on evaluation 
can be counterproductive. The client may think that you are disputing their right to specify the 
project from the very beginning, or that you merely can’t read. Either way, this is not a good start. 
If the team truly feels the design approach has been poorly chosen, they can ask for a rationale 
from the client’s liaison engineer. Ultimately, when the final project report is being written, an 
argument may be made for other alternatives under the recommendations section. 
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Since there is little need for a description and evaluation of alternative design approaches, 
we can instead have an expanded restatement of the design work to be performed by the team, 
adding detail to what has been specified by the client, and demonstrating to the client that the 
team has a good grasp of what they are to accomplish. More time can then be spent on the Plan 
of Implementation section because less time was spent on developing design alternatives. 

3. The Vague Statement Of Work 

The statement may have only a loosely stated description of the desired output and say little or 
nothing about a preferred design approach. The client may be looking for signs of creativity in 
the design team. Engineers don't get as much opportunity as they deserve to be creative at this 
initial stage of product specification, so don’t choke. An example of such a statement of work 
follows. 

“Based upon research of the technological developments of communication and 
entertainment devices, our goal is to envision the future developments of this technology. 
With this vision in mind, it is the task to design and build a prototype of an information 
system and application that is centered on the Bluetooth Technology and the Internet. This 
prototype will demonstrate some of the future technological advances that one would see 
in a future Personal Digital Assistant (PDA).” 

The design team is being asked to determine the product as well as design it. Although it 
may be possible that the proposal could be written after enough design work has been done to 
completely specify the product, we can anticipate that this will actually take too long to meet our 
deadline. The proposal should instead have a section of alternative designs with a rich selection 
of possibilities. Then an evaluation section can clearly lay out criteria by which these alternatives 
can be judged, once enough design work has been done to evaluate them. This assures the client 
that you are aligned with the same goals. Then it is important to show that a plan for how the 
decisions will be made exists. This assures the client that a process is in place that maximizes 
the possibility of creative output occurring, which is just what the client wants. 

4. The Process-Oriented Statement Of Work 

The output is vague but the process and/or technology is well defined. This is not ordinary 
for industry, but it does occur. For example, a company may develop an engineering tool. For 
promotional purposes, they may task a design team with any project that well displays the 
strengths of the new tool. They don’t care about the product because the purpose is to show 
off the process. If you go to a technical exhibition as an engineer, you may very well see a sales 
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person designing some flashy bit of technology in ten minutes or less using their new develop¬ 
ment system. It may also be that the client is considering someone else’s technology for adoption 
within their engineering department and has come to us to see if it is suitable. As an example 
of a process-oriented kind of statement, see the following. 

“The purpose of the project is to have a student group develop a working Advanced Video 
Frame Grabber using W Co.’s new Xtreme design tools for FPGAs. The circuit must be based 
on FPGAs; must be developed entirely with W Co. tools; must run as a stand-alone in hardware; 
must be thoroughly documented for use in trade shows and published documentation; must 
at least capture video, but preferably post-process it, just either use multiple FPGA types (e.g., 
Xilinx and Altera) or be set up to use a user’s choice of one FPGA type (Xilinx or Altera).” 

There are many features of a frame grabber that could be specified, but that is plainly inci¬ 
dental to the key use of the correct design approach, which is to use W Co.’s tools. A decision 
matrix would not be about design alternatives. If there is a design matrix, it would be about the 
product specification and what features should be included. 

D. Decision 

In this section you show how the evaluation process identifies the strongest alternative solu¬ 
tion. Your team’s decision governs the rest of your project because it determines the design 
approach you will pursue from here on out. Convincing your client that this approach is superior 
to alternatives is crucial to your proposal argument. 

III. PLAN OF IMPLEMENTATION 

Because this section explains how the work is to be accomplished, it is crucial for “selling” your 
proposal to a prospective client. The reader wants to know that the methods used will, in fact, 
produce the results promised. Because a project is often a single and non-repetitive enterprise, 
its achievement must be based on careful planning within a time limit and a cost budget. If the 
Scope of Work section explains what your team promises to do, the Plan of Implementation 
section convinces your reader that your team can in fact do it. 

A Plan of Implementation describes how you will accomplish your objectives in the face of 
problems that may be encountered on the way. Success depends largely on carrying out the 
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constituent tasks in a sensible sequence and deploying resources to best advantage. In preparing 
a Plan of Implementation, the project team should disaggregate the project into as many defin¬ 
able tasks as possible. Planning is crucial because it will affect both the budget and schedule. 
Both are based largely on the estimated time to complete each of the tasks. 

When clients compare competing proposals with similar costs, they often choose the one 
offering the most comprehensive and convincing Plan of Implementation. For these reasons, the 
methods used to solve the problem or do the job are always given in detail. When the methods 
are unusually innovative, they are described step-by-step, with reasons for each step included in 
sufficient detail to convince the reader that they will work. Include research, design, prototype 
construction (if relevant), testing, and documentation. 

In short, this section explains how you will accomplish the tasks described in the Scope of 
Work. How do you propose to divide up and sequence the work? Who will do what when? 

IV. REFERENCES AND BIBLIOGRAPHY 

This section cites material utilized in providing information for the proposal. References are 
cited explicitly in the text of the document. They include technical journals, texts, newspaper 
articles, or other such sources of material. Some proposals or reports also include a bibliography. 
A bibliography is a list of materials that is relevant and helpful in understanding the subject and 
project in general. Formats for references and bibliography listings are described in the section 
on manuscript form. 

V. FACILITIES 

Often a section describing the facilities to be used follows and amplifies the Plan of Imple¬ 
mentation. You cannot promise work in sterile conditions, for instance, if the proper laboratories 
are not available. Equipment to be used is often described in this section, although sometimes 
it is listed separately. Equipment might range from special computer capabilities to normal 
laboratory equipment, but it must clearly be capable of doing the job. In major proposals, one 
further reason for this section is that it explains what the client will be getting for the overhead 
charges, which often range from 50 to 100% above the cost of actually doing the work. 


34 


SPRING 2010 






ADVANCES IN ENGINEERING EDUCATION 

Evolution of Technical Writing in Senior Design—A Case History 



VI. PERSONNEL/ORGANIZATION CHART 

The people who will be doing the work, or at least the major discipline leaders, are shown in 
the Personnel section. In most cases, a diagram is used to show the major groupings of tasks and 
the group leader for each group of tasks. The diagram shows both the organizational structure 
of the team and the relationship of the team to the sponsor organization, the sponsor liaison or 
project manager, and the faculty advisor. It is typical in this section to make brief comments about 
the special capabilities of each group leader and to amplify these comments in the appendix with 
a fully developed one or two-page resume of all persons shown in the organization chart. 

VII. SCHEDULE 

This section places all of the tasks that were developed through planning the project from 
beginning to end into a time flow diagram. This diagram can be as simple as a Gantt chart, 
or more complex in the form of a CPM (Critical Path Method) schedule or a PERT (Program 
Evaluation and Review Technique) schedule. The time flow diagram shows the dates on which 
various deliverables, representing ongoing phases of the project, are submitted to the sponsor. 
A discussion of the project management techniques in ensuring that the deliverable schedule 
can be met should be included in this section. The items noted in the schedule should repeat 
exactly the items discussed in Scope of Work and Plan of Implementation. 

VIII. BUDGET 

The section on the costs of the proposed project is crucial. In a well-written proposal, the 
reader should be convinced that the expense is justified. Sometimes costs are detailed in a sec¬ 
tion separate from the proposal so that they will not influence other deliberations; sometimes 
they are presented first on a special budget sheet. In any case, all costs should be itemized under 
headings such as salaries, capital equipment, expendable equipment, miscellany, and overhead. 
Often only estimates are possible, but they obviously should be made with the greatest care. 
In industry, at least, expensive cost overruns are rarely tolerated. 


SPRING 2010 


35 







ADVANCES IN ENGINEERING EDUCATION 

Evolution of Technical Writing in Senior Design—A Case History 


3. Appendices 

As in all written documents, Appendices should contain supplemental material that cannot easily 
and concisely be placed in the body of the document. In the case of proposals, Appendix A should 
include a copy of the statement of work from the sponsor, sometimes called the request for proposal 
(RFP); Appendix B includes student resumes; and Appendix C includes previous work that the team 
or company has done in areas similar to those covered by the statement of work. 


IV. MANUSCRIPT FORM 


A. General Considerations 

Most companies and agencies have a publication standard and the following guidelines are typi¬ 
cal of such corporate standards. The Project Center used Tetra Tech, Inc., a civil engineering firm, 
as a source in assembling these guidelines. 

The proposal must be printed using a laser-quality printer, single-spaced on one side only, on 
standard 8'A by 11" white paper. Use Times New Roman 12 point, or a similar serif font, as well as left 
justification of text (not full justification). Since different team members will likely be working on 
your documents, use compatible word processors to facilitate making changes and/or corrections. 
An equation or technical symbol that is not supported by your word processor may be written in 
manually. 

Left and right margins should be one inch from the top, bottom, left, and right sides of each 
page. Page numbers should be centered 0.5 inches from the bottom of the page. The pages must be 
numbered consecutively. The front materials are numbered in lower case Roman numerals beginning 
with the page “i” after the title page. The first page of the Introduction is page “1.” 
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B. Headings 

The following are style guidelines for headings: 


I. FIRST LEVEL HEADING 

First level headings are flush left, 14 points in size, in bold, and the words are in uppercase 
letters. There are two blank lines between paragraphs and two lines before and after head¬ 
ings. Use Roman Numerals for First Level Headings. To accommodate varying space needs 
for Roman Numerals, tab over to 0.5 inches (1.27 cm) to type heading text. 

A. Second Level Heading 

The second level heading is flush left, 12 points in size, in bold, with words in title case (first 
letters of important words capitalized). There is one blank line between paragraphs and one 
line before and after headings that are second level or lower. Use capital letters as in outline 
form. 

7 . Third Level Heading 

The third level heading is flush left, 12 points in size, in italics, and in title case. Use num¬ 
bers. 

a. Fourth Level Heading 

The fourth level heading is flush left, 12 point, and in title case. Use small letters. 


C. Figures And Tables 

Readers generally prefer having figures and tables distributed throughout the body of the report, 
although it is also permissible to collect them together at the end of the document. Each figure/table 
should be cited and thoroughly explained in the text. Imagine giving an oral presentation with the 
figure/table on a slide or overhead transparency. Your narrative text should be a transcription of 
what you would say to explain the figure/table. 

Figures and tables should each be numbered consecutively using Arabic numerals (e.g., Figure 1, 
Figure 2, Table 1, Figure 3). Every figure/table should include a caption that fully identifies what is 
being illustrated, with important words capitalized. For example: 

Figure 1. Signal-to-Noise Characteristic of the Encoder 

Figure 2. Cantilever Retaining Wall 

Table 1. Standard Load Results 
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Figures are captioned beneath the diagram; tables are captioned at the top of the tabular 
data. 

Figures are drawings, pictures, graphs, and every illustration that is not a table. Photographs, 
oscillograms, and line drawings are typical types of figures. Circuit schematics, block diagrams, 
and flow charts are figures. Words on the face of figures should be kept to a minimum and must 
be readable. Portions of a figure may be identified by letters and explained in the caption. Tables 
are compact, orderly arrangements of facts and data, usually in rows and columns. They are often 
a clear and concise way of summarizing results. 

After the Table of Contents, a List of Figures and a List of Tables must be provided. Show an ac¬ 
curate page number for each figure and table. 

D. Creating a Table of Contents automatically in Word 

It is not necessary to manually type in all the entries for a table of contents for your proposal 
or final report, as long as you use a few simple shortcuts during the writing phase. Following are 
explicit instructions for creating a table of contents (TOC) when using Microsoft Word as your word 
processor. It is known that Word’s procedure for generating the table occasionally errs, but a little 
juggling and retrying generally leads to a satisfactory result. 

7 . Prepare the configuration 

Click on the menu item View:Toolbars and be sure that the Formatting toolbar has been checked. It 
normally is because this toolbar contains the font and font-size drop-down boxes. It also includes the 
Styles drop-down box, which shows 'Normal’ as its default. This will be key to simple TOC generation. 

Click on the drop-down control of the Styles text box. See Figure 1. 

It will display the characteristics of the currently available headings. Check them against the style 
requirements on page 16 of these Writing Guidelines. If they are incorrect, you will want to format 
them. Otherwise, you can continue to step 2. 

Formatting Styles: Select the menu item Format:Style. This brings up a dialog box. For the drop 
down box labeled ‘List’, select ‘All styles’. By clicking on the styles ‘Normal’, ‘Heading I’, etc., you 
can see descriptions of each. 

Click on Modify for any style which is incorrect. See Figure 2. Clicking on the Format button al¬ 
lows you to choose which items to modify, as can be seen in Figure 3. 

Choosing Font, Paragraph and Numbering seems to cover most items. See Figure 4, Figure 5, 

and Figure 6 as examples. 

2. Enter body of proposal 

As you type, and you find a place to use a heading, start a new line, click on the drop arrow next 
to the ‘Normal’ text box, and choose the appropriate heading level. 


38 


SPRING 2010 





ADVANCES IN ENGINEERING EDUCATION 

Evolution of Technical Writing in Senior Design—A Case History 




Z Times New Roman 

- 


Comment Reference 

=- § 

8 pt 

i 


Comment Text 

= H 

10 pt 



Default Paragraph Font 

== a 



Heading 1 

■= n 

12 pt 



Heading 2 

§= n 

14 pt 



Heading 3 

■= H 
13 pt 



Normal 

■=■ 
12 pi 


Figure 1: Styles Drop Down Box with misformatted Headings. 



Figure 2: Modify Style Dialog. 


3. Generate Table of Contents 

When you are ready, place the cursor on a blank page where the table should go. From the 
menu, select Insert: Index and Tables... 

When the dialog comes up as shown in Figure7, choose the Table of Contents tab at the top. Of 
the possible styles, the one from the template, pictured, or the one called Fancy would be acceptable 
for the proposal. Click OK to generate the TOC. You will want to provide a title for the table later. 
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Language... 

Frame... 

Numbering.,, 


Figure 3: Dialog with Format box dropped. 


V. REFERENCES AND BIBLIOGRAPHY 


Each publication and organization has specific guidelines to follow in citing references. There¬ 
fore, authors must consult their guidelines prior to submitting work. As examples, publication 
guidelines for American Society of Civil Engineers (ASCE), American Society of Mechanical En¬ 
gineers (ASME), and the Institute of Electrical and Electronics Engineers (IEEE) can be found at 
the following URLs: 

www.pubs.asce.orq/authors/index.html#ref 

www.asme.org/pubs/MS4.htm l#PREPARING 

www.ieee.org/orqanizations/pubs/magazines/author99.pdf (pages 6 and 7) 

For your proposal and project report, follow the method described in these Proposal Guidelines. 
Project Center proposal and report references are to be numbered in the order in which they appear 
in the text of the document. 
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Figure 4: Font Dialog with correct First Level Heading. 


Citations 

The numbered reference citation should be slightly above the line (superscript) and after the period or 
other punctuation. In the case of two citations, the numbers should be separated by a comma. 1 - 2 In the case 
of more than two references, the beginning and ending numbers should be separated by a dash. 3-5 

Cite a reference to support statements that are not in the general body of engineering or science 
knowledge. For example: 


Cyanobacteria are able to make vertical movements by regulating their buoyancy within 
the water column through intercellular gas vacuoles. 1 This mechanism gives this group 
of phytoplankton the advantage of locating themselves within a stable water column in 
a position of optimal light and nutrient availability with the ability to adjust positions as 
conditions change. 2 - 3 


List of References. 

References for cited material should be listed together at the end of the document in the order 
of their appearance in the text. Each reference must have a corresponding citation in the text of 
the document. 
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Figure 5: Paragraph Dialog with correct First Level Heading. 



Figure 6: Bullets and Numbering Dialog with correct First Level Heading. 
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Figure 7: index and Tables dialog. 


References related to above example: 

1) Walsby, A.E. 1969. “The permeability of blue-green algal gas-vacuole membranes to gas.” Proc. R. Soc. Lond. Ser. 
B, Biol. Sci. 173:235-255. 

2) Walsby, A.E., and M.J. Booker. 1980. “Changes in buoyancy of a planktonic bluegreen alga in response to light 
intensity.” Br. Phycol. J. 15:311-319. 

3) Reynolds, C.S., R.L. Oliver, and A.E. Walsby. 1987. “Cyanobacterial dominance: the role of buoyancy regulation in 
dynamic lake environments.” N.Z. J. Mar. Freshwater Res. 21:379-390. 


Sample References 

Formats for citing source material from various publications are given below. 

Book: 

1) Erickson, P.A., D.E. Cowles, and S.M. Wilson. 1979. Environmental Impact Assessment Principles and Applications. 
2nd ed. Academic Press, Inc., New York, NY. 395 pp. 

Specific Pages of Book: 

2) Clifford, H.T., and W. Stephenson. 1975. An Introduction to Numerical Classification. Academic Press, Inc., New York, 
NY. pp. 193-201. (Note: if citing single page - p. 193.) 

Editor, Compiler as Author of Book: 

3) Marchalonic, J.J. (ed) . 1976. Comparative Immunology. John Wiley & Sons, New York, NY. 538 pp. 
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4) Cresser, M.S., and B. L. Sharp (eds). 1981. Annual Reports on Analytical Spectroscopy. The Royal Society of Chem¬ 
istry, London, UK. 300 pp. 

Journal Article: 

5) Young, D.R., M.D. Moore, T-K. Jan, and R.P. Eganhouse. 1981. “Metals in Seafood Organisms Near a Large California 
Municipal Outfall.” Marine Pollution Bull. 12:134-138. 

Proceedings of a Meeting or Conference: 

6) Low, W.C. 1976. “Pollutional Implications of Canning Wastes.” pp 77-84. In: Proc. of the Fourth International Agri¬ 
cultural Waste Symposium. Rpt. No. 39. Amer. Soc. Agric. Waste Specialists, Norman, OK. 

Individual as Author of Government Report: 

7) Rouse, J.V. 1977. “Geohydrologic Conditions in the Vicinity of Bunker Hill Company Waste Disposal Facilities, Kel¬ 
logg, Shoshone County, Idaho -1976.” EPA-330/2-77-006. U.S. Environmental Protection Agency, National Enforcement 
Investigations Center, Denver, CO. 46 pp. 

Federal Register: 

8) U.S. Environmental Protection Agency. 1979. “Guidelines Establishing Test Procedures for the Analysis of Pollutants; 
Proposed Regulations.” U.S. EPA, Washington, D.C. Federal Register Vol. 44, No. 233, Part III. pp. 6943-6955. 

Municipal Document: 

9) Los Angeles, City of. 1980. “Annual summary monitoring report for 1979.” 15 pp. + 8 tables. 

(Note: Avoid citing as City of Los Angeles) 

Section from the Code of Federal Regulations: 

10) Code of Federal Regulations. 1985. State and Local Air Monitoring Stations (SLAMS). Title 40, Section 58.13. Office 
of Federal Register, National Archives and Records Administration. U.S. Government Printing Office, Washington, DC. 

Map: 

11) U.S. Geological Survey. 1968. Seattle North, Wash. 7.5 Minute Series. NE/4 Seattle 151 Quadrangle. (N4737.5 
W12215/7.5). USGS, Denver, CO. 

Thesis or Dissertation: 

12) Layne, F.M. 1976. “The Relationship Between Frog Survival and Temperature.” Ph.D. Dissertation. Ohio State Uni¬ 
versity, Columbus, OH. 41 pp. 

Newspaper Article (signed): 

13) Torvig, S. 1981. "Diagnosis for Puget Sound: Sick.” Seattle Times, 1 February 1981, Seattle, WA. p. A-2. 

Newspaper Article (unsigned): 

14) Seattle Post-Intelligencer. 1981. “Red-Tide Hits.” 23 June 1981, Seattle, WA. p. B-7. 

Web page: 

15) Forrest, S., P. Burrows, and M. Thompson. 2000. The dawn of organic electronics, <http://www.spectrum.ieee. 
orq/pubs/spectrum/0800/orqs.html> . Accessed 2000 Nov 9. 

BIBLIOGRAPHY 


The bibliography, in contrast to the list of references, includes materials not cited in the text that are 
helpful in understanding the subject. The format for the bibliography is the same as for references. However, 
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while references are listed in order of citation in the text, the bibliography is alpha by author’s last name. 
A list of references is required in Project Center proposals and reports; a bibliography is optional. 


VI. EVALUATING PROPOSALS 


In this section we present a series of checklists or scales that readers can use to evaluate propos¬ 
als. By knowing how your proposal will be read and evaluated, you can develop a plan for revision 
to ensure that your proposal will make a strong positive impression on your readers. The faculty 
members in each engineering department use these checklists as they read and grade proposals 
from each team in their department. 

A. Reader’s Checklist For Evaluating Proposals 

What follows is a checklist used by readers to evaluate your proposal. Your team can use the 
same checklist to help you evaluate and revise draft versions of your proposal. 

Questions for Structure and Clarity 

1. Does the proposal follow the Project Center Writing Guidelines for document design? 

2. Does the proposal follow the Project Center Writing Guidelines for design and labeling of 
figures and tables? Are figures and tables properly referenced in the text? 

3. Does the Table of Contents exactly match the headings in the body? 

4. Is the right information in the right section? 

• Introduction (background, problem statement, design parameters/criteria specified by 
sponsor) 

• Scope of Work (literature review, specification of deliverables, tasks or subtasks to be ac¬ 
complished) 

• Plan of Implementation (timeline, division of labor, other aspects of when, where, and 
how) 

5. Is there keyword and structural consistency throughout (e.g., tasks specified in letter of trans¬ 
mittal match tasks specified in body; tasks predicted early in the proposal match those de¬ 
veloped later; key words are repeated consistently without variation; Plan of Implementation 
parallels Scope of Work) 

6. Does the first sentence of the Introduction provide an overview of the problem to be addressed 
(either by summarizing the problem or summarizing the task to be accomplished)? 

7. Is the proposal appropriately developed (neither too thin nor overly elaborated)? 
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8. Is the prose clear (reader doesn’t get lost; requires no backtracking and puzzling: NOTE: Lack 
of clarity can result from either sentence-level or structural confusion)? 

9. Could a non-technical manager understand the proposal? 

10. Is there an absence of sentence-level noise (misspellings, grammatical errors, non-parallelism 
in lists, etc.)? 

Questions for Technical Content: 

1. Does the proposal create confidence in the team’s technical ability and professional thor¬ 
oughness? 

2. Does the proposal reveal an adequate design process? 

3. Does the proposal reveal good understanding of technical issues? 

4. Does the team’s design approach show creative and analytic thought? 

B. Reader’s Feedback Sheet For Proposal Drafts 

First Impression-Document Design: [Follows Project Center manuscript guidelines for heading, page 
format, etc.; has cover, letter of transmittal, title page, TOC (and list of figures/tables), Introduction, 
Scope of Work, Plan of Implementation; headings in TOC match headings in body; figures and tables 
are correctly labeled and referenced in text] 

HIGHLY PROFESSIONAL AVERAGE WEAK 

Reader Friendliness: [Reader energy stays focused on content rather than structure; dear organi¬ 
zation; parts in right place; parts clearly related to whole; follows old/new contract; sentences are 
grammatically correct and coherent; absence of noise; reader seldom gets lost] 

PLEASURE TO READ READER HAS TO WORK HARD OFTEN LOST 

Evidence of Technical Mastery: [Quality and depth of work; adequacy of design process; good 
understanding of technical issues; evidence of both creative and analytical thought; professional 
thoroughness] 

STRONG AVERAGE WEAK 

Letter of Transmittal: [Makes good first impression; summarizes problem and team's design ap¬ 
proach; creates confidence in team’s professionalism] 

STRONG AVERAGE WEAK 

Introduction: [Opens with summary of project’s purpose; states problem clearly; shows un¬ 
derstanding of the problem from a technical standpoint; specifies sponsor-provided param¬ 
eters/criteria that must be met; shows problem’s significance to company; provides needed 
background] 

STRONG AVERAGE WEAK 
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Scope of Work (specification of work to be accomplished and deliverables): [Clearly shows what 
the team will do; often breaks the work into stages or subgoals; deliverables clearly specified] 

CLEARLY STATED AVERAGE CONFUSING 

Scope of Work (alternative solutions/evaluation): [Shows alternative approaches to solving prob¬ 
lem; outlines strengths and weaknesses of each approach; specifies criteria for choosing best design 
approach; convinces reader that criteria are appropriate; applies criteria clearly using decision ma¬ 
trix. (If alternative solutions are not applicable, proposal explains and justifies their absence—e.g., 
sponsoring company specified design approach)] 

STRONG AVERAGE WEAK 

MISSING (explained and justified) MISSING (not explained) 

Plan of Implementation: [Explains how the team will accomplish Scope of Work; disaggregates the 
task into definable subtasks; explains timeline and division of labor; when appropriate describes 
methods to be employed; convinces reader of team’s professionalism and dependability 

STRONG AVERAGE WEAK 


C. Holistic Scoring Scale For Proposals 

This last scale is a scoring guide readers will use to rank your proposal against criteria for excellence. 
Scores of 6 or 5: Are generally clear and well written; meet criteria; convince reader of solid engi¬ 
neering and computer science competence. 

6 : A proposal receiving a 6 reveals a high level of professional competence, giving reader con¬ 
fidence in the technical ability of the team and the thoroughness of its work. A 6 proposal is 
strong in all criteria: document design, reader friendliness, quality of engineering and computer 
science, and appropriate and clear writing in the main body headings of Introduction, Scope of 
Work, and Plan of Implementation. Although the writing may contain minor errors in sentence 
structure or occasional unclear passages, the overall impression should be highly positive. 

5: A proposal receiving a 5 also reveals a high level of professional competence, giving reader 
confidence in the technical ability and thoroughness of the team. A 5 proposal is strong in most 
criteria but may have one or two sections that need revision. If the reader becomes confused at 
one point, further reading should quickly get the reader back on track. Although the 5 proposal 
is not as strong as a 6 , it nevertheless represents high quality work. The reader should feel that 
reworking one section or making a few systematic changes would turn the proposal into a 6 . 

Scores of 4 or 3: Are less successful than a 5 or 6 because they are either (!) frequently confus¬ 
ing or (2) leave reader unconvinced of the significance or quality of engineering and computer 
science. They must have some positive features, convincing reader that the team approaches 
the problem in a professional manner. 
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4: A 4 still has many positive strengths but is substantially weaker than a 5 or a 6 proposal. A 4 
proposal may give readers confidence in the technical and professional ability of the team, but 
may be marred by unclear passages, places that need more development, grammatical lapses 
and noise, or a tone and style that seems amateurish rather than professional. A score of 4 may 
also be appropriate for a well-written proposal that has made little progress in its research and 
design so that the proposal contains little evidence of creative and analytical thought. Finally, 
a score of 4 is appropriate for a well-written proposal that fails to convince the reader that the 
project’s design is innovative or makes improvements over an existing prototype. In such a case 
the engineering or computer science design seems routine or conceptually thin. 

3: A 3 proposal has some strengths, but its overall impact is unsatisfactory. It may typically be 
deficient in one of the following three ways: 

a. A3 proposal confuses the reader at the macro level. Often the statement of the problem is 
unclear, and the reader is unable to use the subsequent Scope of Work and Plan of Imple¬ 
mentation to “read backwards” to clarify the problem. Sometimes the parts don’t match 
a consistent whole (e.g., the problem as stated in the letter of transmittal doesn’t match 
the introduction, or the scope of work doesn’t match the plan of implementation.) 

b. A3 proposal may be clear at the macro level but so unclear at the micro level that the 
reader must struggle excessively. Such lack of clarity might stem from needless use of 
jargon, inconsistency of terms, disorganized paragraphs, failure to follow the old/new 
contract, or grammatical confusion. 

c. A3 proposal may also have surface clarity but leave the reader with major questions 
about the value of the project as an engineering or computer science contribution. 
The proposal gives the reader the impression of major gaps in thinking, serious lack of 
development of ideas, and/or content thinness. 

What makes a 3 proposal better than a 2 or 1 is the presence of positive strengths in 
some criteria. A 3 proposal should give a technical reader confidence in the team’s 
engineering and computer science ability. 

Score of 2 or 1: Are very confusing; leave a strongly negative impression; few redeeming strengths 

2: A 2 proposal gives a strongly negative impression of the team with few compensatory strengths. 
The 2 proposal bewilders the reader with the same kind of macro or micro confusion as the 3 
proposal, but conveys a sense of unprofessional thinking about the problem, lack of a profes¬ 
sional approach to design, and unengaged writing. Often a 2 proposal has missing parts and 
gives the technical reader a sense of inadequate technical thinking. 

1: A 1 proposal meets few if any of the criteria and gives a negative impression of both the team’s 
writing skills and its technical competence. 
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VII. WORKING WITH THE WRITING CENTER 


The Writing Center is staffed by Seattle University students who have been nominated by faculty 
for their writing ability and for their interpersonal skills. All new Writing Center consultants enroll in 
English 390 “Tutoring Writing: Theory and Practice,” an intensive 5-credit course. Your Writing Center 
consultant can help your team create and revise drafts leading to a topquality final document. 

A. Relationship of the Writing Center and Faculty Advisor to Your Design Project 
7. The project team’s responsibilities 

The team’s job is to write the proposal and project report within a time frame that allows for meaning¬ 
ful discussion and useful feedback from the consultant. This means the team should coordinate a writing 
schedule with the consultant that allows for ample discussion time before drafting or revising each 
section and at least 24 hours for the consultant to read each draft before meeting with the team. 

2. The faculty advisor’s responsibilities 

The faculty advisor is the academic authority to whom the team reports. Throughout the proj¬ 
ect process, including the writing of the proposal and project report, the advisor works with team 
members and writing consultant on ideas, focus, clarity, organization, and purpose of the team’s 
writing. The faculty advisor gives final review and approval before the proposal or project report is 
submitted to the Project Center 

3. The Writing Center consultant’s responsibilities 

The consultant’s job is to serve as a general reader who will find and suggest improvements in 
overall clarity, organization, and correctness in the project proposals and completion reports. To 
do this, schedule time in advance for the consultant review you draft documents and then to meet 
with the team to discuss the drafts. The consultants may not be familiar with writing these kinds of 
documents, so bring your copy of the Writing Guidelines with you and share them with the Writing 
Center consultants every time you give them a draft to review. 

B. Context for Your Written Proposal 

Here is the context that your proposal should address: 

• A sponsoring company has written a Request for Proposal (RFP) seeking a solution to an engi¬ 
neering or computer science problem. 

• A number of engineering teams plan to bid for the project; therefore, your team’s proposal is 
only one of several being considered by the company. 

• Your task is to write a persuasive proposal to demonstrate to your sponsor that you have a 
firm grasp of the problem situation at hand. 
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The Writing Center consultant will read the proposal as though they were in the role of a non¬ 
technical manager who is a key player in deciding which firm to hire. On the basis of your proposal, 
why should the sponsoring company hire your team, instead of a team from another firm? Writing 
Center consultants are not engineers or computer scientists, so they cannot roleplay technical read¬ 
ers analyzing the effectiveness of your technical solutions. That is the job of your Faculty Advisor 
and Sponsor Liaison. As professional engineers and computer scientists, you will frequently need to 
write to mixed audiences—both technical audiences who will be analyzing the technical portions of 
your report and lay audiences who make managerial decisions. Managerial readers will be interested 
in the general soundness, professionalism, clarity, flow, and persuasiveness of your arguments. 

C. Typical Problems with Proposals 

Past project teams produced proposals that varied widely in quality. By being aware of potential 
problems in advance, your team can develop a system of brainstorming, discussing, drafting, revising, and 
editing that results in a winning document. Here is a list of the problems most frequently encountered: 

• weak grasp of the problem situation 

• confusing organization 

• lack of transitions 

• unclear sense of purpose or focus for various sections of the proposal 

• unclear writing 

• confusing inconsistencies 

• lack of logic in headings 

• inadequate attention to the needs of an audience, particularly the needs of an audience in¬ 
terested in the managerial or business side of the project as opposed to the technical side 

• assumption that visuals are self-explanatory—e.g., visuals with confusing titles, unclear purpose 
or function, and an overload of “bell and whistle” effects at the expense of clarity 

• obvious inconsistencies in writing style and formatting from section to section 

• inadequate appreciation for a context in which writers have to “win” audience’s approval. 

D. Procedures for Cycling Through the Writing Center 

1. Early in fall quarter get to know your team’s assigned consultant and workout times when the 
Writing Center consultant and the team members are free. Your consultant will make every 
effort to meet with your team at a time convenient to all of you. 

2. Arrange for an initial one-hour appointment with your consultant to talk through your team’s 
conception of your project and an early draft of your proposal. Use the questions for brain¬ 
storming, in Section E, to facilitate your discussion. 
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3. As your project develops, schedule sufficient quality time for drafting and revising your pro¬ 
posals. Try to write drafts as you go along rather than wait to the end. (Good writing is very 
time-consuming. Recognize that your first drafts will need substantial dismantling and exten¬ 
sive rewriting. Such rewriting is demanded of almost all writers and is a function of the writing 
process. It is not a sign of weak writing skills.) 

Throughout the quarter your consultant will be available for help as needed either with individu¬ 
als or with your team as a whole. Once you have completed a draft, forward a copy to the Writing 
Center so that your consultant can study it prior to a Writing Center session. 

Plan to meet with your consultant at least three times during the proposal development to discuss 
drafts. Schedule a session late in the quarter for final editing. 

If problems arise, please contact Professor Larry Nichols, the Director of the Writing Center, for 
assistance. His number 296-5309 and his email address is Inicholsf&seattleu.edu . 

E. Questions for Brainstorming Your Proposal 

The following questions will help you brainstorm ideas for the main sections of your proposal 
as explained later in these guidelines. The questions marked with an asterisk (*) are especially use¬ 
ful for your first Writing Center conference, where your team’s goal is to understand the problem 
thoroughly and be able to explain the problem to your consultant. The remaining questions will help 
you brainstorm ideas after your initial rounds of research and design. 

Brainstorming Questions 

(Questions marked with an’ should be discussed during first Writing Center Conference) 

1. 'What engineering or computer science problem has the sponsoring company asked you to 
solve? 

2. 'What background information can you provide about the sponsoring company? How big a 
company is it? How profitable is it? How does this company make its money? To whom does 
your liaison engineer report? 

3. ’From a business and management perspective, how will the company benefit from having this 
problem solved? Why does management have an interest in this problem? 

4. 'Why hasn’t the company solved this problem already? What makes this an interesting problem 
from a technical perspective? 

5. What does the existing literature say about the problem your team must solve? How can a 
literature search help you avoid reinventing the wheel? 

6. What are the alternative solutions or design approaches? [For most proposals, your team will 
need to design several alternative solutions and scrutinize them carefully. An important part 
of your proposal will be your examination of more than one way to solve the problem. You will 
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need to choose the best solution and argue for it on the basis of criteria established either 
by your group or by the sponsoring company.] 

7. What criteria will you use to choose the best solution? [In most proposals, you will display these 
criteria in a decision matrix. Often the criteria are explicit in the RFP. At other times you need to 
establish the criteria, usually in consultation with your liaison engineer and project advisor.] 

8. What solution to the problem or design approach does your team propose? How does your 
solution meet the criteria better than alternative solutions? 

9. 'What deliverables must you produce by the end of the project? What are the stages of work 
or subtasks that you must accomplish? Specify the exact work you will perform for the client. 
[Your answers to this question will go into the “Scope of Work” section of your proposal.] 

10. 'What process does your group plan to use in order to accomplish the work? Who will do what 
tasks when? [Your answers to this question will go into the “Plan of Implementation” section 
of your proposal.] 


VIII. SOME QUICK SUGGESTIONS FOR WRITING AS A TEAM 


Below are some quick suggestions that may help you compose as a team. 

1. Do as a team what teams do best. Do as individuals what individuals do best. 

Teams are good at the following: 

• Brainstorming for ideas 

• Achieving creative solutions to problems 

• Planning and organizing activities/setting goals 

• Developing an organizational plan for a document and determining what ideas go into 
which parts 

• Serving as readers who give feedback on drafts 

• Seeing how individual pieces fit into the whole and making recommendations for improve¬ 
ments of individual pieces 

Teams are not good at the following: 

• Writing drafts of individual sections 

• Editing for uniform voice and style 

2. Recognize that the pieces of any document make sense only in relation to the whole. Never 
draft individual pieces until all team members understand the whole. 

3. Talk about your document before you write it. As a team, talk your way through each section 
of the document. Working together and taking notes on a large sheet of drawing paper, plan 
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each section of the document. Articulate its purpose and its content. Each member of the team 
should feel qualified to write any section of the document. This crucial step can be greatly 
facilitated by your Writing Center consultant. 

4. Include visuals such as figures, graphs, charts, or tables only if your team can explain why a 
reader needs them. Visuals for their own sake confuse readers rather than help them. The docu¬ 
ment should be able to stand on its own with all visuals removed, because essential information 
displayed on the visuals should also be discussed verbally in the document itself. 

Follow Project Center guidelines for manuscript form from the start. All team members should 
use the same word-processing program and follow the same plan for manuscript form, font sizes, 
heading styles, and so forth. (Follow exactly the guidelines in this document.) Reformatting a docu¬ 
ment late in the writing process is very time-consuming. 

Assign individual team members the responsibility of drafting sections of the document. Copies 
of the drafts should be made for all group members, faculty advisor, and your Writing Center con¬ 
sultant. At a team meeting with your consultant, team members should review drafts for accuracy, 
completeness, clarity, development, and style. Individual writers should then revise their sections. 
One team member, preferably the best writer, should do final editing of the document so that it 
seems written in one voice. 

Write your document as you proceed with your work rather than putting off writing until the very 
end. The act of trying to write a section of the proposal can clarify and drive your thinking. The more 
you write as you go along, the easier it will be at the end to produce a quality proposal. 
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Appendix B 


A. Instructions 

Please rank the proposals on a scale of 1 through 6. A 6 being very strong and 1 being very weak. 
You may use the rankings in part B to decide on the holistic scoring in part C. 

B. Reader’s Feedback Sheet For Proposal 

First Impression—Document Design: [Follows Project Center manuscript guidelines for heading, 
page format, etc.; has cover, letter of transmittal, title page, TOC (and list of figures/tables), Intro¬ 
duction, Scope of Work, Plan of Implementation; headings in TOC match headings in body; figures 
and tables are correctly labeled and referenced in text] 

Very Strong Very Weak 

6 5 4 3 2 1 

Letter of Transmittal: [Makes good first impression; summarizes problem and team’s design ap¬ 
proach; creates confidence in team’s professionalism] 

6 5 4 3 2 1 

Introduction: \Opens with summary of project's purpose; states problem clearly; shows under¬ 
standing of the problem from a technical standpoint; specifies sponsor-provided parameters/crite¬ 
ria that must be met; shows problem’s significance to company; provides needed background] 

6 5 4 3 2 1 

Scope of Work (specification of work to be accomplished and deliverables): [Clearly shows what 
the team will do; often breaks the work into stages or subgoals; deliverables clearly specified] 

6 5 4 3 2 1 

Scope of Work (alternative solutions/evaluation): [Shows alternative approaches to solving prob¬ 
lem; outlines strengths and weaknesses of each approach; specifies criteria for choosing best design 
approach; convinces reader that criteria are appropriate; applies criteria clearly using decision ma¬ 
trix. (If alternative solutions are not applicable, proposal explains and justifies their absence—e.g., 
sponsoring company specified design approach)] 

6 5 4 3 2 1 

Plan of Implementation: [Explains how the team will accomplish Scope of Work; disaggregates 
the task into definable subtasks; explains timeline and division of labor; when appropriate describes 
methods to be employed; convinces reader of team's professionalism and dependability 

6 5 4 3 2 1 

Reference and Bibliography: [References used in the preparation of the proposal are listed; the 
format follows a consistent pattern; references include author, name of publisher, year and volume 
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whenever appropriate; persona / communications and websites and properly referenced; reader can 


track down all references, if needed.] 




Very Strong 



Very Weak 

6 5 4 

3 

2 

1 


Reader Friendliness: [Reader energy stays focused on content rather than structure; dear organi¬ 
zation; parts in right place; parts clearly related to whole; follows old/new contract; sentences are 
grammatically correct and coherent; absence of noise; reader seldom gets lost] 

6 5 4 3 2 1 

Evidence of Technical Mastery: [Quality and depth of work; adequacy of design process; good understand¬ 
ing of technical issues; evidence of both creative and analytical thought; professional thoroughness] 

6 5 4 3 2 1 

Substantial Effort: [Evidence that the team has put in substantial effort in completing the project] 
6 5 4 3 2 1 


C. Holistic Scoring Scale For Proposals 

This last scale is a scoring guide readers will use to rank your proposal against criteria for 
excellence. 

Scores of 6 or 5: Are generally clear and well written; meet criteria; convince reader of solid engi¬ 
neering and computer science competence. 

6: A proposal receiving a 6 reveals a high level of professional competence, giving reader con¬ 
fidence in the technical ability of the team and the thoroughness of its work. A 6 proposal is 
strong in all criteria: document design, reader friendliness, quality of engineering and computer 
science, and appropriate and clear writing in the main body headings of Introduction, Scope of 
Work, and Plan of Implementation. Although the writing may contain minor errors in sentence 
structure or occasional unclear passages, the overall impression should be highly positive. 

5: A proposal receiving a 5 also reveals a high level of professional competence, giving reader 
confidence in the technical ability and thoroughness of the team. A 5 proposal is strong in most 
criteria but may have one or two sections that need revision. If the reader becomes confused at 
one point, further reading should quickly get the reader back on track. Although the 5 proposal 
is not as strong as a 6 , it nevertheless represents high quality work. The reader should feel that 
reworking one section or making a few systematic changes would turn the proposal into a 6 . 

Scores of 4 or 3: Are less successful than a 5 or 6 because they are either (!) frequently confus¬ 
ing or (2) leave reader unconvinced of the significance or quality of engineering and computer 
science. They must have some positive features, convincing reader that the team approaches 
the problem in a professional manner. 
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4: A 4 still has many positive strengths but is substantially weaker than a 5 or a 6 proposal. A 4 
proposal may give readers confidence in the technical and professional ability of the team, but 
may be marred by unclear passages, places that need more development, grammatical lapses 
and noise, or a tone and style that seems amateurish rather than professional. A score of 4 may 
also be appropriate for a well-written proposal that has made little progress in its research and 
design so that the proposal contains little evidence of creative and analytical thought. Finally, 
a score of 4 is appropriate for a well-written proposal that fails to convince the reader that the 
project’s design is innovative or makes improvements over an existing prototype. In such a case 
the engineering or computer science design seems routine or conceptually thin. 

3: A 3 proposal has some strengths, but its overall impact is unsatisfactory. It may typically be 
deficient in one of the following three ways: 

a. A 3 proposal confuses the reader at the macro level. Often the statement of the problem is 
unclear, and the reader is unable to use the subsequent Scope of Work and Plan of Implementa¬ 
tion to “read backwards” to clarify the problem. Sometimes the parts don’t match a consistent 
whole (e.g., the problem as stated in the letter of transmittal doesn’t match the introduction, 
or the scope of work doesn't match the plan of implementation.) 

b. A 3 proposal may be clear at the macro level but so unclear at the micro level that the reader 
must struggle excessively. Such lack of clarity might stem from needless use of jargon, incon¬ 
sistency of terms, disorganized paragraphs, failure to follow the old/new contract, or gram¬ 
matical confusion. 

c. A 3 proposal may also have surface clarity but leave the reader with major questions about the 
value of the project as an engineering or computer science contribution. The proposal gives 
the reader the impression of major gaps in thinking, serious lack of development of ideas, 
and/or content thinness. 

What makes a 3 proposal better than a 2 or 1 is the presence of positive strengths in some crite¬ 
ria. A 3 proposal should give a technical reader confidence in the team’s engineering and computer 
science ability. 

Score of 2 or 1: Are very confusing; leave a strongly negative impression; few redeeming strengths 

2: A 2 proposal gives a strongly negative impression of the team with few compensatory strengths. 
The 2 proposal bewilders the reader with the same kind of macro or micro confusion as the 3 
proposal, but conveys a sense of unprofessional thinking about the problem, lack of a profes¬ 
sional approach to design, and unengaged writing. Often a 2 proposal has missing parts and 
gives the technical reader a sense of inadequate technical thinking. 

1: A 1 proposal meets few if any of the criteria and gives a negative impression of both the team’s 
writing skills and its technical competence. 
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Appendix C 


A. Instructions 

Please rank the reports on a scale of 1 through 6-6 being very strong and 1 being very weak. You 
may use the rankings in part B to decide on the holistic scoring in part C. 


B. Reader’s Feedback Sheet For Project Reports 

First Impression - Document Design: [Follows Project Center manuscript guidelines for heading, 
page format, etc.; has cover, letter of transmittal, title page, TOC (and list of figures/tables), intro¬ 
duction, Scope of Work, Plan of Implementation; headings in TOC match headings in body; figures 
and tables are correctly labeled and referenced in text] 


Very Strong 




Very Weak 

6 5 

4 

3 

2 

1 


Reader Friendliness: [Reader energy stays focused on content rather than structure; dear organi¬ 
zation; parts in right place; parts clearly related to whole; follows old/new contract; sentences are 
grammatically correct and coherent; absence of noise; reader seldom gets lost] 


Very Strong 




Very Weak 

6 5 

4 

3 

2 

1 


Evidence of Technical Mastery: [Quality and depth of work; adequacy of design process; good 
understanding of technical issues; evidence of both creative and analytical thought; professional 


thoroughness] 





Very Strong 




Very Weak 

6 5 

4 

3 

2 

1 


Letter of Transmittal: [Makes good first impression; summarizes problem and team’s design ap¬ 
proach; creates confidence in team’s professionalism] 


Very Strong 




Very Weak 

6 5 

4 

3 

2 

1 


Executive Summary/Abstract: [Ability to synthesize the project background, purpose, design ap¬ 
proach and along with conclusions and recommendations; should be selfconta/ned; le. Reader should 
be able to understand the main features of the project by reading this part.] 


Very Strong 




Very Weak 

6 5 

4 

3 

2 

1 
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Introduction: [Opens with summary of project’s purpose; states problem clearly; shows understand¬ 
ing of the problem from a technical standpoint; specifies sponsor-provided parameters/criteria that 
must be met; shows problem’s significance to company; provides needed background] 

Mery Strong Very Weak 

6 5 4 3 2 1 

Design Methodology (alternative solutions/evaluation): [this section is specific to the project; it 
could cover the following, but is not restricted to: design alternatives considered; specifies criteria 
for choosing best design; sampling approach; applies decision matrix, when appropriate.] 

Very Strong Very Weak 

6 5 4 3 2 1 

Conclusions and Recommendations: [Makes conclusions based on the work carried out; comes up 
with thoughtful recommendations for future work.] 


Very Strong 




Very Weak 

6 5 

4 

3 

2 

1 


Reference and Bibliography: [AH references used In the project and in the preparation of the report 
are listed; the format follows a consistent pattern; references include author, name of publisher, year 
and volume whenever appropriate; personal communications and websites and properly referenced; 
reader can track down all references, if needed.] 


Very Strong 




Very Weak 

6 5 

4 

3 

2 

1 


Substantial Effort: [Evidence that the team has put in substantial effort in completing the project] 
654321 


C. Holistic Scoring Scale For Reports 

This last scale is a scoring guide readers will use to rank your report against criteria for excel¬ 
lence. 

Scores of 6 or 5: Are generally dear and well written; meet criteria; convince reader of solid engi¬ 
neering and computer science competence. 

6 : A report receiving a 6 reveals a high level of professional competence, giving reader confidence 
in the technical ability of the team and the thoroughness of its work. A 6 report is strong in all 
criteria: document design, reader friendliness, quality of engineering and computer science, and 
appropriate and clear writing in the main body headings of Introduction, Scope of Work, and 
Plan of Implementation. Although the writing may contain minor errors in sentence structure 
or occasional unclear passages, the overall impression should be highly positive. 
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5: A report receiving a 5 also reveals a high level of professional competence, giving reader 
confidence in the technical ability and thoroughness of the team. A 5 report is strong in 
most criteria but may have one or two sections that need revision. If the reader becomes 
confused at one point, further reading should quickly get the reader back on track. Although 
the 5 report is not as strong as a 6, it nevertheless represents high quality work. The reader 
should feel that reworking one section or making a few systematic changes would turn the 
report into a 6 . 

Scores of 4 or 3: Are less successful than a 5 or 6 because they are either (1) frequently confusing 
or (2) leave reader unconvinced of the significance or quality of engineering and computer science. 
They must have some positive features, convincing reader that the team approaches the problem 
in a professional manner. 

4: A 4 still has many positive strengths but is substantially weaker than a 5 or a 6 report. A 4 
report may give readers confidence in the technical and professional ability of the team, but 
may be marred by unclear passages, places that need more development, grammatical lapses 
and noise, or a tone and style that seems amateurish rather than professional. A score of 4 may 
also be appropriate for a well-written report that has made little progress in its research and 
design so that the report contains little evidence of creative and analytical thought. Finally, 
a score of 4 is appropriate for a well-written report that fails to convince the reader that the 
project’s design is innovative or makes improvements over an existing prototype. In such a case 
the engineering or computer science design seems routine or conceptually thin. 

3: A 3 report has some strengths, but its overall impact is unsatisfactory. It may typically be de¬ 
ficient in one of the following three ways: 

a. A 3 report confuses the reader at the macro level. Often the statement of the problem is 
unclear, and the reader is unable to use the subsequent Scope of Work and Plan of Imple¬ 
mentation to “read backwards” to clarify the problem. Sometimes the parts don’t match 
a consistent whole (e.g., the problem as stated in the letter of transmittal doesn’t match 
the introduction, or the scope of work doesn’t match the plan of implementation.) 

b. A 3 report may be clear at the macro level but so unclear at the micro level that the reader 
must struggle excessively. Such lack of clarity might stem from needless use of jargon, 
inconsistency of terms, disorganized paragraphs, failure to follow the old/new contract, 
or grammatical confusion. 

c. A 3 report may also have surface clarity but leave the reader with major questions about 
the value of the project as an engineering or computer science contribution. The report 
gives the reader the impression of major gaps in thinking, serious lack of development of 
ideas, and/or content thinness. 
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What makes a 3 report better than a 2 or 1 is the presence of positive strengths in some criteria. 
A 3 report should give a technical reader confidence in the team’s engineering and computer sci¬ 
ence ability. 

Score of 2 or 1: Are very confusing; leave a strongly negative impression; few redeeming strengths 
2: A 2 report gives a strongly negative impression of the team with few compensatory strengths. 
The 2 report bewilders the reader with the same kind of macro or micro confusion as the 3 
report, but conveys a sense of unprofessional thinking about the problem, lack of a professional 
approach to design, and unengaged writing. Often a 2 report has missing parts and gives the 
technical reader a sense of inadequate technical thinking. 

1: A 1 report meets few if any of the criteria and gives a negative impression of both the team’s 
writing skills and its technical competence. 
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